Pull Request Test Coverage Report for Build 1407

• 63 of 64 (98.44%) changed or added relevant lines in 4 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.005%) to 98.638%

Totals
Change from base Build 1404:	-0.005%
Covered Lines:	4057
Relevant Lines:	4113

💛 - Coveralls

While I don't have a problem with the implementation (a bit hacky though), this situation makes me feel like it's a dilemma.
SQLAlchemy is very popular that there are many tools built based on it, including db migration, web framework integration and profiler in this case.
On one hand, I think we definitely should support those features, or at least expose interfaces for other packages to implement; on the other hand, those existing tools may already have many users who have got used to them, and it might be hard, even conflicting, to support all the synchronous libraries, as it's not the same way to think in sync and async.
But, well, let's admit, inventing new tools takes a lot of time and effort, which can be hard for a full-time job, let alone for part-time maintainers.

I want to say no, but I can't give a solution to that, so I'll hope someday we can have a better, more async friendly solution.

(Sorry, I haven't checked what SQLTap does and how much effort to rebuild an async version.)

Revisited this PR.
I think rowcount will be useful in some cases.
I'm not sure about the event part, as we already have #161 and #435. Do you want to have a more complete implementation instead?

Oh yeah, I felt the same way as you did. A complete implementation would be nice, but I don't know how yet.